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(57) Abstract: A device, system and method are described for parsing and propagating end user identity received from a terminal 
( 1) involved in a wireless session to an application in a gateway server (13). The PLMN (7) of which terminal (1) forms part provides 
access to external networks including a PSTN (9). In addition to conventional telephone operations, the terminal (1) provides its user 
with access to the internet (11) via the gateway server (13). The gateway server (13) may be operated by a service provider or perhaps 
a particular organisation such as a bank which for security reasons wishes to keep control of the gateway server (13). Software 
through which the transactions are carried out is provided by various so-called back-end applications resident on an applications 
server (17). A trust server (30) is provided which is connectable to the gateway server (13) controlling access to the application 
server (17). 
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METHOD, DEVICE AND SYSTEM RELATING TO TRANSACTION SECURITY 

IMPROVEMENT IN AND RELATING TO TRANSACTION SECURITY 

5 The present invention relates to transaction security, particularly, although not 
exclusively, in electronic commerce. 

The arrival of electronic commerce on a large scale has removed one of the 
traditional safeguards when carrying out a transaction, namely the physical 
10 presence of the parties and/or the means of payment. Whereas, in the past it 
was at least possible to compare a signature on a credit card or cheque with a 
specimen or even to present a credit card to a card reader for verification, this 
is clearly no longer an option when transactions are being carried out remotely 
as is the case with those transaction taking place over the Internet. 

15 

It has been recognised that the different priorities exist for the purchaser and i 
vendor of products/services in Internet based transactions. From the 
purchaser's perspective, she may be presented with a large number of 
potential vendors most if not all could be previously unknown to her. When 

20 attempting to transact with her selected vendor she will want to be confident 
that she can trust the vendor. However, unlike a conventional face to face 
transaction she cannot make any form of assessment of the trustworthiness 
of the vendor based on the condition of the vendors premises, his staff, other 
customers and the like. Similarly, the vendor has the difficulty of receiving 

25 many requests from people unknown to him all of whom purport to have 
legitimate means for making payment. 

Attempts have been made from each perspective to overcome these 
problems. Thus, in the case of the purchaser there has been quite universal 
30 adoption of a session-based protocol namely the Secure Sockets Layer 
Protocol. This protocol in its overwhelmingly most common guise permits a 
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session to be established in which the identity of a server possibly under the 
control of the vendor is made available in the form of a certificate generated in 
accordance with the principles of the Public Key Infrastructure (PKI). The 
purchaser is thus able to assure herself that the server operator has a 
5 certificate in which she is prepared to place her trust, the certificate therefore 
acts as a form of guarantee of the good faith of the server owner. 

In the case of the vendor, the approach adopted to resolve the problem has 
depended largely on the nature of the business relationship with the 

10 purchaser. Thus, where a pre-existing relation is in place, perhaps the 
purchaser is a customer of a bank with which she wishes to carry out a 
transaction, then one approach has been to provide the purchaser with 
passwords in the form of shared secrets. Hence, such passwords need to be 
supplied before a transaction takes place. The provision of passwords before 

15 the transaction takes place is clearly not feasible where the transaction is 
between parties having no pre-existing or continuing relationship. In such a 
case, the vendor may be forced simply to carry out off-line checks on the 
validity of credit cards and the like. 

20 According to one aspect of the present invention there is provided a 
transaction security device for connection to a network including at least one 
terminal, the device comprising a server operable to validate data provided by 
a terminal over said connection in order to establish a secure session, the 
device being operable to respond to a request from said terminal to access an 

25 application by obtaining said previously validated data from said server and 
forwarding said data to said application along with said request. 

Advantageously, this merging of the security approach results in increased 
confidence for both parties to a transaction. The purchaser is no longer 
30 reliant merely on the assumption that the vendor is the party behind the 
session and the vendor has greater confidence in the identity of the purchaser 
and furthermore in the case of the pre-existing customer relationship, is able 



WO 02/43346 



PCT/EP01/00984 



3 

to dispense with the overheads and complexity involved in administering a 
separate security solution. 

According to a further aspect of the invention, there is provided a trust server 
5 connectable to a gateway server controlling access to a remote server, the 
trust server comprising a validator and data storage, wherein the validator is 
responsive to a first request from said gateway server to deliver status 
information relating to data received by said gateway server and to store said 
data in said storage such that said data is retrievable by said gateway server 
1 0 for inclusion in a request to said remote server. 

Advantageously, the validation of the data by the server removes the 
requirement for the extensive data-entry required by application level security. 
This has the benefit of both reducing the amount of data-entry required from 
15 the user and also cutting down on log-in time and the possibility of error. It 
also removes a perceived barrier to the adoption of electronic commerce, 
namely that of complexity; if the user believes that too many steps are 
required to access a service, she will not use it. 

20 According to a still further aspect of the invention, there is provided a 
transaction security system comprising a server connected to a network 
including at least one terminal, the server being operable to validate data 
provided by a terminal over said connection in order to establish a secure 
session therewith, said server being further operable to respond to a request 

25 from said terminal for access to an application by providing said validated 
data to said application, such that a determination on whether to permit 
access by said terminal is made by said application in response to said 
validated data. 

30 Whilst according to a yet further aspect of the invention, there is provided a 
transaction security method for a server connected to a network, the method 
comprising acting on a request to establish a secure session over a network 
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connection including validating data received in said request and following 
establishment of said session acting on a further request to access an 
application by providing at least part of said previously validated data to said 
application for authentication and/or encryption purposes. 

5 

In order to aid in understanding the present invention, a particular 
embodiment thereof will now be described by way of example and with 
reference to the accompanying drawings, in which: 

10 Figure 1 is a diagrammatic view of a transaction security system according to 
the present invention; 

Figure 2a is a more detailed view of the system of Figure 1 with the 
intermediate infrastructure omitted for clarity; 

Figure 2b is a similar view to Figure 2b with elements of a gateway server 
15 omitted for clarity; 

Figure 3 is a signal diagram illustrating a method according to the present 
invention; 

Figure 4 is a similar view illustrating further steps in the method of Figure 3; 
Figure 5 is a diagrammatic view of the system of Figure 1 in accordance with 
20 a further aspect of the invention, and 

Figure 6 is a similar view of the system of Figure 1 in accordance with a still 
further aspect of the invention. 

Referring to the Figures and in particular Figure 1, there is shown terminal 1 
25 having a display 3 and a set of keys 5 including alphanumeric keys. Through 

these keys 5, a user is able, via a user interface, to operate the terminal 1 . 

The terminal 1 forms a mobile element of a Public Land Mobile Network 

(PLMN) 7 the operation of which will be well known to those skilled in the art. 

It will noted that the PLMN 7 provides access to external networks including a 
30 Public Switched Telephone Network (PSTN) 9. 
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In addition to conventional telephone operations, the terminal 1 provides its 
user U with access to the Internet 11 via a gateway server 13. The gateway 
server 13 may be operated by a service provider or perhaps a particular 
organisation such as a bank which for security reasons wishes to keep control 
5 over the gateway server 13. A pool of modems 15 connected to the PSTN 9 
provides dial-up access from the terminal side to the gateway server 13. 
Other access routes may be employed depending on the capability of the 
terminal 1 and PLMN 7. 

1 0 As part of its service to customers, an organisation such as a bank B allows 
transactions such as money transfers, share dealing and so on to be carried 
out electronically using a terminal 1 and an Internet 11 connection. Software 
through which the transactions are carried out is provided by various so-called 
back-end applications resident on an applications server 17. Again, for 

15 security reasons, the applications server is located in premises of the bank B. 

In the case of a terminal 1 connected to the PSTN 9, access to a back-end 
application is provided via the gateway server 13. In this example the 
gateway server 13 is located on the premises of the bank B although there is 
20 nothing to prevent locating the gateway server 13 anywhere there is access to 
the Internet 1 1 . The gateway server 1 3 facilitates the exchange of information 
between the terminal 1 and a remote server connected to the Internet and/or 
intranet, in this case the bank's own back-end applications server 17. 

25 As shown in Figures 2a in further detail, the gateway server 13 comprises a 
number of functional elements. Firstly, a transport layer block 19 with which 
the terminal 1 initially negotiates access; secondly, a session data store 21 ; 
thirdly, a request handler 23 and fourthly an http-connector 25. Furthermore, 
these elements have a number of external connections. Thus the transport 

30 layer block 19 and request handler 23 are connected 27, 29 to elements of a 
trust server 30. These elements include a signature validator 31 and a 
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certificate validator 33. In addition to the external connections 27,29, with the 
gateway server 13, the trust server 30 has internal connections 35 between 
the two validators 31,33 and to a configuration store 37 and an external 
connection 39 between the trust server 30 and the Internet 11. This latter 
5 connection 39 permits the trust server 30 to determine the status of 
information presented to it by the gateway server 13. 

Referring again to the gateway server 13, the http-connector 25 is also 
provided with an external connection 41 to the Internet 11. Through this 
10 connection 41 web servers including an application server 17 providing back- 
end applications may be reached. 

As will be further elaborated below, the terminal 1 together with the 
constituent elements of the gateway server 13 each makes use of the 
15 wireless Public Key Infrastructure (wPKI). To enhance further the security 
provided by the gateway 13, the trust server 30 includes a local cache for both 
certificates and Certificate Revocation Lists (CRL) 43,45. Regular downloads 
of CRL are made to the cache from a public directory 47 connected to the 
Internet 1 1 . The CRLs are signed by appropriate Certification Authority (CA). 

20 

Before the terminal 1 can be employed by the user in electronic transactions a 
number of processes are necessary to establish the security necessary to 
satisfy both the user and the organisation, in this case the bank B, with which 
she is carrying out her transactions. 

25 

Consequently, to enable access to the gateway 13 and the backend 
applications beyond, the terminal 1 is provided with a tamperproof smart card 
or token 49 which acts as a carrier for data used to substantiate the identity of 
the terminal user U. During a session, the terminal 1 acts as a conduit for the 
30 data stored on the token 49 which is used in securely accessing the relevant 
back-end application. 
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The token 49 is manufactured by a card manufacturer which is then delivered 
to a service provider perhaps the operator of the PLMN, Following delivery, 
the service provider SP, in this case the operator of the PLMN 7, commences 
5 personalisation of the token 49 by generating and then storing two unique 
private/public key pairs on the token 49. Thus there is are provided two 
private keys and their corresponding public keys, providing respectively, an 
authentication key and a non-repudiation key. In addition, the service 
provider root certificate, and URLs pointing to the service provider's SP 
10 certificates of the public keys are stored on the token 49. The URLs are 
formed using an identifier of the token 49 as key data. At this stage however, 
no certificates yet exist. Thus, the URLs on the card are void and therefore 
unusable. 

15 The user U completes personalisation during acquisition of the token 49. 
Thus, the user U personally identifies herself to an authorised employee of 
the service provider SP using a passport or the like. The employee confirms 
the completed strong identification of the user with his own digital signature, 
which is then stored by the service provider. The token 49 is then physically 

20 handed over to the user U who may now insert it into her terminal 1 for normal 
mobile telephony purposes. In the meantime, the service provider SP 
associates the identifier of the token 49 with the user's subscription. The 
service provider SP further requests its own Certification Authority (CA) to 
create certificates for the two public keys on the user's token. The certificates 

25 identify the user U as the subject of the certificates, and refer to the token 
identifier. The CA generates the certificates, stores them on the private 
certificate Directory 47 of the service provider SP, and returns an OK 
response to the service provider SP. The service provider SP prints from its 
database the authentication objects or PINs for the two private keys on the 

30 token 49, and sends them through the post to the user U. 
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With reference to Figure 3 and Figure 2a, the user U is now in a position to be 
able to register herself as a certified user of the organisation, in this case the 
bank B, with which she wishes to carry out electronic transactions. Thus, the 
user U firstly initiates a call 101 to the access number of a registration service. 
5 The terminal 1 physically connects to the dedicated gateway server 13 located 
in the bank's B premises and then attempts to set up a secure session 
between the terminal 1 and the gateway server 13. 

The transport layer block 19 of the gateway server 13 responds 103 by 
10 identifying itself with its server certificate and requesting the authentication of 
the User U. Information identifying the bank B is derived by the terminal 1 
from the gateway server certificate and delivered 104 to the user U via the 
display 3. At the same time, the Terminal 1 requests a response from the 
user U in the form of an authentication PIN1 . Using the keypad 5, the user U 
15 enters 105 her PIN1. Providing the correct PIN1 has been entered the 
terminal 1 then sends 106 a response to the transport layer block 19 
containing the URL of the service provider's certificate of the authentication 
key, the response having been signed using the authentication key stored on 
user's token 49. 

20 

The transport layer block 19 of the Gateway server 13 forwards the 
authentication response to request handler 23 which passes it to the 
certificate validator 33 of the Trust Server 30. As shown in more detail in 
Figure 5, the certificate validator 33 comprises time critical 51 and non-time 

25 critical 53 elements, the first of which, namely the time critical element 51 is 
activated on receipt of the forwarded authentication response. Hence, the 
validator 33 identifies the URL containing the service provider's certificate and 
contacts 108 a corresponding Directory 47 to check the validity of the service 
provider's certificate for the user U. The Directory 47 responds 109 to the 

30 Trust Server 30 with information about the certificate and its status such as its 
validity period. The outcome of the check is reported 110 to the transport 
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layer block 19 of the trust server. If the status of the certificate is OK, a 
"session secured" message is sent 1 1 1 to the terminal 1 and a secure session 
is initiated 113, furthermore, the contents of the certificate are stored for the 
duration of the session in the secure session data store 21 . However, before 
5 the terminal 1 informs 112 the user U via the display 3 that a secure session 
is now active between the terminal 1 and the gateway server 13, the 
certificate validator 33 carries out the non-time critical element 53 and 
accesses the CRL cache 45 in an attempt to determine the revocation status 
of the certificate. If no certificate is present in the cache 45, a CRL fetch for 
10 the information from the CRL directory 47 is initiated. In either case, the 
revocation status of the certificate is obtained. If the CRL reveals that the 
certificate has been revoked, a message to this effect is displayed to inform 
the user U. The message may include details of the revoked certificate*. 

15 In the event that the certificate has been revoked, the session is terminated. 
However, should the certificate be in force then the terminal 1 can complete 
negotiation of the session in accordance with the selected protocol. This may 
include the generation of shared secrets such as would be understood by 
those skilled in the art. Whereupon, the terminal 1 is able to send 114 a user 

20 authentication request to the registration service of the organisation, in this 
case the bank B. 

Referring now in particular to Figure 4, the request is passed by the transport 
layer block 19 to the request handler 23 which retrieves the contents of the 
25 service provider's certificate from the data store 21 and includes them in a 
header attached to the request. The request, including its header, is then 
routed by the http-connector 25 via the Internet 1 1 to the bank registration 
service which is running on a backend server 17. 

30 The bank registration service recognises the request as being for registration 
of a user and extracts the certificate data from the request header. The bank 
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registration service compares the certificate data and in particular the token 
identity with a customer record directory and seeks to make a match with a 
previously created record. In the event that no match is found a message to 
that effect is delivered to the terminal and the session is closed. However, if a 
5 match is made the bank registration service responds by sending 115 an 
acknowledgement text together with a request that the user U enters her non- 
repudiation PIN2 at the Terminal 1 to confirm her identity (see Figure 2b). 

The terminal 1 displays 116 the text and the user U duly enters 117 her non- 
10 repudiation PIN2 using the keypad 5 of the terminal 1 . Assuming the PIN2 is 
correctly entered, the terminal 1 uses the private non-repudiation key on the 
token 49 to sign the response in the manner known to those skilled in the art 
of asymmetric cryptography. The response is sent 1 18 via the gateway server 
13 (not shown) to the backend server 17 running the bank registration service. 
15 The bank registration service receives the response and forwards 1 1 9 it to the 
Trust Server 30 for the authentication of the signature by the signature 
validator 31. The signature validator checks the signature in the received 
message using the public certificate of the non-repudiation key in the manner 
well known to those skilled in the art of asymmetric cryptography. Thus, the 
20 trust server obtains the certificate by requesting 120 it from the Directory 
47containing the non-repudiation public key. The Directory 47 provides 121 
the trust server 30 with the certificate details and the trust server 30 returns 
122 the results of its analysis of the signature to the bank registration service. 

25 If the status of the certificate was OK and the signature itself was OK, the 
bank registration service requests 123 that the Trust Server 30 checks 
whether there already exist Bank certificates for the user's token 49. The 
Trust Server 30 interrogates 124 the Bank's certificate Directory 47 to 
determine whether there are certificates associated with the token 49. The 

30 token identifier contained in the header with the original registration request 
from the terminal 1 is thus used as the search term in this query. The 
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directory 47 returns 125 its data to the trust server 30. If, as a result of this 
check by the trust server 30, the trust server 30 informs 126 the bank 
registration service that there were already certificates associated with the 
user's token 49 in the Bank's certificate Directory 47, the terminal is informed 
5 127 and a corresponding message is displayed 128 by the terminal 1 and the 
user U is informed that the registration has already been done and the 
registration session is closed. Otherwise, the bank registration service 
requests an update 128 of the Customer record directory with the information 
that a token 49 holding the certificates of the Bank is a valid authentication 
1 0 method for the user U. 

Subsequently, the bank registration service causes an "authentication 
successful" message to be delivered to the terminal 1 . The user is then able 
to read 131 a message generated 130 on the display 5 informing the user that 
15 registration was successful and that it will be completed after the Bank's 
certificates have been sent to the user's terminal 1 . 

Delivery of the certificates may take place by any suitable method including 
over the air using a SMS route, by a push session either originated by the 
20 bank registration service or indeed whilst the registration session is still active. 

The user U is now in a position to be able to access the transactional facilities 
made available to her by the bank B, but using the bank's certificates to 
establish a secure session over the gateway server 13 to the backend 

25 transaction application of the bank B. In some cases such as simple balance 
enquires and the like it maybe sufficient only for the transactional application 
to be satisfied that the session has been established using a valid bank 
certificate in accordance with the process described above in relation to the 
service provider certificate including a check to determine whether the bank 

30 certificate has not been revoked. However, where a more sensitive 
transaction is being carried out, such as the transfer of money between 
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accounts or making a trade, then the transaction application may, as a further 
security step, request that a transaction acknowledgement be signed by the 
User U using her non-repudiation PIN2 to cause the terminal 1 to sign the 
acknowledgement using the non-repudiation key which may then be checked 
5 by the trust server 1 as previously described above including checking the 
CRL to determine the revocation status of the certificate relating to the non- 
repudiation key. 

It may well be the case that a gateway server 13 is required to provide access 
10 to a plurality of applications operated by different organisations (Figure 6). 
The owner of the gateway server 1 3 could be an organisation such as a bank 
which could provide the facility to other organisations reluctant or enable to 
invest in establishing their own gateway. As such, the server 13 is required to 
provide access not only to applications corresponding to those already 
15 described but also to so-called legacy applications. Such a legacy application 
may be incapable of extracting certificate information from the header of a 
request passed to it by the http-connector module 25. 

Hence, the gateway server 13 further includes an access control module 55 
20 which interprets the received request from a terminal 1 and queries the 
session data store 21 which may also hold details of access rights and the like 
for the applications accessible from the gateway 13. Preferably however, the 
access rights are stored permanently outside of the session data store 21. 
This information may be pre-stored, or could be created dynamically following 
25 a failure to communicate certificate information to an application in the 
manner previously described. 

Thus, following the authentication of a user as described previously, the 
ensuing request from the terminal 1 is interpreted by the access control 
30 module 55 which establishes firstly whether authorisation of the user is 
required as might be the case for the abovementioned legacy applications. If 
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not, the access control module then passes to the next stage of identifying the 
access rights including the URLs necessary to access the application on the 
back-end server 17. As previously described, the request handler then places 
the certificate information together with any information intended to be 
5 included from the data store in a header to the request. The subsequent 
processing of the request then follows the steps previously described 
including the CRL check and the optional non-repudiation step. 

Alternatively, if the application is identified by the access control 55 as a 

10 legacy application, then the access module 55 optionally initiates an 
authorisation step. Whether such a step is required is determined by the 
access control module 55 which has access to the data store 21 and the 
particular records for that application. For example, the records may include, 
in the form of a profile, how the owner of an application wishes particular 

1 5 requests to be handled. In order to authorise the user; a request is sent to the 
terminal 1 which displays a message asking the user to enter her non- 
repudiation PIN2. Once the PIN2 has been correctly entered, the terminal 1 
signs the response using the non-repudiation private key and sends the 
response to the gateway server 13 where it is intercepted by the access 

20 control module 55. The access control module 55 asks the request handler 
23 to contact the trust server 30 whose signature validator 31 validates the 
signature against the relevant certificate. Assuming the signature is validated 
then the access control module 55 allows the original request from the 
terminal to be passed to the http-connector 25 and thus to the back-end 

25 server 17' on which the legacy application is resident, but not before the 
certificate has been checked against the CRL cache as described above. 

It will be appreciated by those skilled in the art that no reference has been 
30 made to a particular protocol for use in establishing a secure session between 
a terminal and a gateway server. One example of such a protocol is the 
Wireless Transport Layer Security Specification (WTLS) dated 18 February 
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2000, which specification forms part of the Wireless Application Protocol 
published by the Wireless Application Protocol Forum. Similarly an example 
of one particular embodiment of a token is that set out in another specification 
published by the Wireless Application Protocol Forum, namely the Wireless 
5 application protocol Identity Module (WIM) dated 5 November 1999. The 
cryptographic tools necessary to provide the functionality set out in the above 
description are well known to those skilled in the art of asymmetric 
cryptography, nevertheless, the particular tools required to provide such 
functionality in the case of the WAP protocol may be further studied in the 

1 0 specification published by the Wireless Application Protocol Forum, namely 
the WMLScript Crypto Library dated 5 November 1999. Furthermore, the 
skilled addressee will recognise that the initial registration process outlined in 
the embodiment is but one of many available. One such alternative process 
might be to utilise self-signed certificates rather than have them issued by a 

15 service provider. 
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CLAIMS 

1 . A trust server connectable to a gateway server controlling access to a 
remote server, the trust server comprising a validator and data storage, 

5 wherein the validator is responsive to a first request from said gateway 

server to deliver status information relating to data received by said 
gateway server and to store said data in said storage such that said 
data is retrievable by said gateway server for inclusion in a request to 
said remote server. 

10 

2. A trust server as claimed in Claim 1, wherein the remote server 
provides access to one or more applications. 

3. A trust server as claimed in Claim 1 or Claim 2, wherein the data is 
1 5 received from a terminal. 

4. A trust server as claimed in Claim 3, wherein the terminal is a mobile 
station. 

20 5. A trust server as claimed in any preceding Claim, wherein the data is 
received from an application. 

6. A trust server as claimed in any preceding Claim, wherein the data 
comprises a public key certificate. 

25 

7. A trust server as claimed in Claim 6 as appendant to Claim 3, wherein 
the private key corresponding to said public key certificate is stored on 
said terminal. 

30 8. A trust server as claimed in Claim 7, wherein the private key is stored 
within a token. 
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9. A transaction security device for connection to a network including at 
least one terminal, the device comprising a server operable to validate 
data provided by a terminal over said connection in order to establish a 
5 secure session, the device being operable to respond to a request from 

said terminal to access an application by obtaining said previously 
validated data from said server and forwarding said data to said 
application along with said request. 

10 10. A device as claimed in Claim 9, wherein the data comprises a public 
key certificate. 

11. A device as claimed in Claim 10, wherein the private key corresponding 
to said public key certificate is stored on said terminal. 

15 

12. A device as claimed in Claim 11, wherein the private key is stored 
within a token. 

13. A device as claimed in any one of Claims 9 to 12, wherein the terminal 
20 is a mobile station 

14. A transaction security system comprising a server connected to a 
network including at least one terminal, the server being operable to 
validate data provided by a terminal over said connection in order to 

25 establish a secure session therewith, said server being further operable 

to respond to a request from said terminal for access to an application 
by providing said validated data to said application, such that a 
determination on whether to permit access by said terminal is made by 
said application in response to said validated data. 



30 



15. A system as claimed in Claim 14, wherein the data comprises a public 
key certificate. 
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16. A system as claimed in Claim 15, wherein the private key 
corresponding to said public key certificate is stored on said terminal. 

5 17. A system as claimed in Claim 16, wherein the private key is stored 
within a token. 



18. A system as claimed in any one of Claims 14 to 17, wherein the 
terminal is a mobile station. 

10 

19. A transaction security method for a server connected to a network, the 
method comprising acting on a request to establish a secure session 
over a network connection including validating data received in said 
request and following establishment of said session acting on a further 

15 request to access an application by providing at least part of said 

previously validated data to said application for authentication and/or 
encryption purposes. 

20. A method as claimed in Claim 19, including generating said secure 
20 session request in a terminal connected to said network. 



21. A method as claimed in Claim 19 or Claim 20, including generating 
said application access request in a terminal connected to said 
network. 

25 

22. A method as claimed in any one of Claims 19 to 21, wherein the data 
comprises a public key certificate. 



23. 
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A method as claimed in Claim 22 as appendant to Claim 20, wherein 
the private key corresponding to said public key certificate is stored on 
said terminal. 
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24. A method as claimed in Claim 23, wherein the private key is stored 
within a token. 

25. A method as claimed in Claim 23 and any Claim dependant therefrom, 
5 wherein the terminal is a mobile station. 

26. A computer program comprising executable code for execution when 
loaded on a computer, wherein the computer is operable in accordance 
with said code to carry out the method according to any one of Claims 

10 19 to 25. 



27. 



A program as claimed in Claim 26, stored on a computer readable 
medium. 
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